When businesses receive new data for their computer systems, they typically must validate that data before it can be processed. For example, when a bank receives a new loan application, the information contained in the application is examined and determined to be legitimate and complete before the application is processed. If the application fails validation, processing may halt and the data in the application may be corrected before processing can proceed.
There are many different types of validation. Validation logic may apply to a single data item. The validation logic can determine if a data value is the correct type (e.g. Numeric, alphanumeric, text, etc.) And the correct length. The validation logic can also determine if the data value is a member of a specified set of values (e.g. Ea valid two character state code) or if it falls within a specified range of values. Alternatively, validation logic may involve multiple data items and the validity of the relationships between them. For example, validation logic might dictate that a loan amount cannot be greater than ten times the amount of equity. Validation logic can become arbitrarily complex. Some validations may be conditional (i.e. The application of the validation is dependent upon the successful execution of a conditional statement). For example, some loan validation rules might only apply to certain types of loans. The concept of validation encompasses any logic that examines one or more data items and determines a Boolean outcome of true or false.
The implementation of validation logic has a number of problems associated with it. First, the creation of validation logic is a time consuming and costly endeavor. Many systems contain hundreds or even thousands of validation rules. In current application development, the validation logic typically may not be created or tested independently from the application; i.e. The application must be executed in order to execute the validation logic. This provides a very inefficient means to create and test validation logic. In addition to the cost of creating validation logic, it is also difficult and costly to maintain validation logic. Since it is usually not well segregated from the other application logic, it cannot be managed and maintained as a separate IT asset. Over time it typically becomes harder and more costly to maintain due to inadequate documentation, staff turnover, etc. The implementation and maintenance of validation logic also suffers from a lack of business visibility into the process. Validation logic typically may be defined or approved by business users, yet there are few or no tools that make it possible for business users to participate directly in rule creation, testing, or maintenance. Their participation is usually limited to reviewing documentation that is not generated directly from the implementation of the validation logic. Such documentation is costly to maintain and over time often diverges from the implementation due to lack of diligence or resources.
Once created, validation logic may be difficult to reuse inside other applications within the enterprise and between enterprises. In the past, many large enterprises have relied on mainframes to be the sole domicile of their business logic. However, the internet has required the use of new application platforms such as J2EE and .NET, making it difficult for an enterprise to maintain their business logic on a single platform. Consequently, validation logic is often implemented and duplicated on multiple platforms within the enterprise. It would be desirable to create and manage validation logic for multiple platforms from a single point of control. In addition to the current difficulties associated with reusing validation logic within an enterprise, it may be difficult to share validation logic with external enterprises. The rise of E-Commerce has increased the amount of B2B interactions and the amount of data that is transmitted electronically between enterprises. These interactions are giving rise to new industry standards for exchanging information. These standards often include validation rules as well as data layout specifications. Yet each enterprise is responsible for its own implementation of the validation logic. This creates inefficiency, redundancy of effort, and costs associated with reconciling different implementations between enterprises. Therefore, it may be difficult for an enterprise to share its validation logic with other enterprises.
Finally, the current implementations of validation logic may not mitigate the cost associated with the manual investigation and correction of invalid data. When data fails validation it often may require manual intervention to investigate and correct the data (i.e. An individual has to research the cause of the failure and either correct the data or the validation rules). This cost may be either borne by the company receiving the data, the company sending the data, or both.